Map generation improvements: modular framework and twelve new generators - #240

#238 (already merged) added CustomGamePreferences.h, which serializes
CustomGameSetup::generator by taking Sint32 MapGenerationDescriptor::*
member pointers directly. #240 replaced generator's type with
GenerationRequest, whose method-specific options live in a generic
std::map<std::string,int> instead of fixed struct fields — an
architecture change, not a rename — so the file no longer compiled.

- CustomGamePreferences::encode()/decode() now convert through
  toLegacyDescriptor()/fromLegacyDescriptor() (the compatibility
  adapter #240 already built for exactly this kind of interop), so the
  on-disk wire format and its corruption-recovery bounds are unchanged.
  decode()'s method-validity check now asks the live GeneratorRegistry
  instead of a hardcoded 1-8 range, so it stays correct as generators
  are added or retired.
- Widened several fields() bounds (terrain weights 0-64 -> 0-100,
  riverDiameter's max 64 -> 65, oldIslandSize 1-64 -> 1-70) to match
  the modular registry's current ranges. These are approximate,
  same as before: the reused legacy fields (e.g. riverDiameter also
  stands in for lake size/channel width/bridge width) don't have one
  true bound, so this is a safe envelope, not a tight per-method one.
  Without this, decode() could reject a preferences file that a normal
  save legitimately produced (oldIslandSize's own default already
  exceeded the old 1-64 bound for any method other than Isles/Old
  Islands).
- Found and fixed a related crash bug in the compatibility adapter
  itself while tracing this: Lattice and Maze register wheat/wood/
  stone/algae controls with no entry in legacyField()'s mapping table,
  so converting either method through toLegacyDescriptor/
  fromLegacyDescriptor threw an uncaught std::invalid_argument. Added
  the four missing mappings (they match pre-existing legacy struct
  fields exactly) and changed every other option with no legacy slot
  (loopiness, home-radius, cell-size, ...) from throwing to falling
  back to its control's default value, so a newer generator's full
  option set can never crash this adapter again.
- test/CustomGameSetupHarness.cpp: preferencesModel()/preferencesScreen()
  built a GenerationRequest via the same member-pointer approach;
  updated both to build a temporary MapGenerationDescriptor and convert.
  Switched preferencesModel()'s method from Old Islands to Crater Lakes
  (one of the four modern height-map generators that still exposes a
  repeat-landscape control; Old Islands never did in the new registry,
  so it always round-tripped back to 0). The per-field assertions in
  preferencesScreen() now compare against the same achievable
  conversion rather than raw field maximums, since only the options a
  method actually registers survive a GenerationRequest round trip.

Verified: full scons -j8 release=1 server=0 client build is clean.
CustomGameSetupHarness passes in default, preferences-write and
preferences-read modes. MapGeneratorDefaultsTest and
MapGeneratorStudy --catalog also pass, unaffected by the adapter fix.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KFxsZmLM4qsovemHqDrHGP

Rebased onto master now that #238 has merged. That surfaced a real compile
break: the harness still called Map::oldMakeIslandsMap/Game::oldMakeIslandsMap,
which the registry-driven generator rewrite removed.

Route it through MapGenerator::generateMap(Game&, const MapGenerationDescriptor&,
seed) instead, which owns map sizing and the game association internally. Seed
explicitly since generation determinism no longer follows the global sync-rand
state.

Also start from setMethodDefaults() rather than hand-picked constants: #238's
defaults tuning tightened several control ranges (island-size moved to 50-70,
the shared "workers" control caps at 8), so the harness's old literals
(oldIslandSize=35, nbWorkers=48) now fail request validation. Defaulting first
and overriding only what this decorative colony actually needs to differ keeps
it from rotting the same way again as ranges keep moving.

Verified: full client and menu-colony-harness build clean; `check`, `navigation`,
and `generate` subcommands all pass (generate grows the colony from 8 to 56
units over the same 12,000-tick warmup, confirming the reduced starting worker
count doesn't defeat the decorative intent).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Le23P4h9QuDjwExuK6HU96

Follow-up to 777b748. That commit's guaranteeStartingResources fixed most
of the fairness gap but left river with a residual ~5% of colonies
reaching no wheat or wood at all, and left old-random's imbalance direction
flipped rather than closed. Investigated the river failures directly (map
dumps + reachability analysis, not just aggregate metrics this time): a
colony's boot tile was landing on a stretch of perfectly good, well
connected land — confirmed by re-flooding the same tile through terrain
alone, ignoring resources, and finding a landmass orders of magnitude
larger than what the resource-respecting flood could reach. A ground unit
can't walk onto a tile carrying a resource (Map::isHardSpaceForGroundUnit
excludes them), and the noise-band resource painting has no idea what it
might wall in, so it was sealing colonies into small pockets on their own
otherwise-fine landmass.

guaranteeStartingResources now detects this directly: when a team's
resource-respecting reachable area is suspiciously small, it re-floods the
same tile blocked only by water (ignoring resources) and diffs the two
results to find exactly the resource tiles forming the wall's face —
clearing only those, not a surrounding neighborhood, and iterating a
bounded number of times in case a wall is thicker than one tile. A colony
on a genuinely small spot (a real islet on a water-heavy map) is left
alone: there's no larger area on the other side of nothing, so the
terrain-only flood finds nothing bigger and the check is a no-op by
construction.

First attempt at this used a blunt fixed-radius clear around the boot tile
whenever the pocket looked too small, gated only on the team actually
being under-served. It worked for river but silently regressed swamp
(whose terrain legitimately includes small real islands): demolishing a
25x25 tile neighborhood around a "small but actually fine" pocket destroys
perfectly good nearby deposits for no gain when there is no larger
landmass to reach. The precise wall-tracing approach here has no such
failure mode, validated below.

Reconfirmed with the same 200-fixed-seed methodology as 777b748: river's
rate of a colony reaching no wheat or wood at all drops from ~5% to ~3%
(the earlier blunt version reached 0% on this seed range but at swamp's
expense — see above), with the remaining cases past this guarantee's own
search radius. Swamp's numbers now improve slightly rather than regressing
(the false-blame that motivated the blunt version's guard is gone: the
gate is precise instead of merely permission-checked). Crater lakes,
islands, old-random and old-islands are unaffected (the mechanism only
fires where floodReach and a terrain-only flood actually disagree).
Generation success rate is unchanged everywhere. Confirmed the existing
map-generator-defaults-test and a full non-server engine build still pass.

Old-random's wheat/wood imbalance (flipped, not fixed, by 777b748) and the
remaining few percent of unreachable river colonies stay open follow-ups,
called out in docs/map-generators/FRAMEWORK_UPGRADES.md along with why a
join symmetric compass-slot assignment was tried and not kept for the
former.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Rc6FTwBEB6LKNUmamX9wWW

The four height-field generators picked colony sites before any resource
was on the map, so a site could only be judged by the shape of the grass
under it: largest contiguous grass rectangle to the first colony, and
everyone after it taking what was left. Every fairness fix so far has been
downstream repair of that decision. This changes the decision.

The ordering turned out not to be a constraint at all. Nothing between the
placement pass and the resource pass reads a boot position or draws from a
random stream, so the two simply swap, and placement can then see what it
is actually choosing between.

Measured the headroom before building anything, via a new `headroom` mode
in the study tool: score every legal site against a single multi-source
flood per resource (one flood answers the question for the whole map, so
scoring a site is a lookup rather than its own search), then find the
narrowest score window still holding enough mutually distant sites. Result:
every map sampled, on every generator, already contained a placement where
all colonies were equally served. The maps were never unfair. The placement
was throwing away fairness the map already had.

shared/StartingPositions::chooseBalancedStarts now picks sites after the
resource pass. A site scores as its *worse* primary resource, since a
colony beside wood but a long walk from wheat is not a good start; sites
are sorted and the narrowest qualifying window wins, scanned from the
low-score end so ties settle in favour of a set that is not merely equal
but good. The legacy search remains as a fallback for maps where no set of
sites can reach both resources.

Across 200 fixed seeds per generator, versus the pre-existing behaviour:
  gap between best- and worst-served colony  9.5-19.0  ->  3.5-4.0 tiles
  worst-served colony's walk to a resource  12.0-18.5  ->  3.5-4.2 tiles
  colonies reaching no wood or wheat at all  up to 5.6% ->  0%
  colonies clearing the study tool's viability bar        all of them
The worst-served colony is now better off than the *luckiest* colony was
before. Verified at 2, 6, 8 and 12 colonies as well (gap 2.4-7.4, widening
with colony count as expected, no generation failures introduced at any
count). Success rates, resource totals and colony separation (30-72 tiles
apart on a 128x128 map) are unchanged. map-generator-defaults-test and a
full non-server engine build pass.

Old-random and old-islands deliberately keep their own placement: they put
resources relative to each boot tile, so moving a colony does not bring its
resources along. The same headroom measurement puts their achievable gap at
8.0 and 0.9 tiles, and old-islands already sits at 0.9.

This changes how these four generators play, and that part is a
maintainer's call rather than a metric's: colonies now start snug against
their wood and wheat instead of in open ground, and buildable room within
reach of the worst-served colony drops 14-28% (still 405-642 free building
sites against a viability bar of 16). Generator revisions are bumped, so a
given seed no longer produces the map it did before.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Rc6FTwBEB6LKNUmamX9wWW

Placement picks a site for its walk to wood and wheat, but a colony
rewrites its own surroundings the instant it is built: placeStarts()
clears a five by seven box of resources to make room, the swarm itself
becomes four by four tiles of obstacle, and the workers spawn on the row
above the boot tile rather than on it. Scoring against the bare map
therefore credited a site with deposits it was about to destroy and paths
it was about to block.

That was measurable, not theoretical. Instrumenting the search on one seed
showed it choosing four sites scored wood 0, wheat 0 apiece -- exactly
equal -- which the finished map then spread across three tiles, because
how much each site loses to its own construction depends on the shape of
the resources around it.

chooseBalancedStarts now shortlists on the cheap bare-map distance, which
can only understate the built cost and so is a sound filter, then re-scores
the shortlist by simulating the finished colony: clearing box excluded,
swarm footprint impassable, flood starting from the worker row. The offsets
mirror placeStarts() rather than approximating it.

Against the previous commit, over 200 fixed seeds per generator:
  gap between best- and worst-served colony  3.5-4.0  ->  0.92-1.02 tiles
  worst-served colony's walk                 3.5-4.2  ->  2.0-2.3 tiles
Better on both counts at once, and level with old-islands, the
fair-by-construction benchmark. Holds at 2, 8 and 12 colonies (gap
0.35-4.70, widening with count as expected, no failures at any count).
Buildable room, resource totals and colony separation are unchanged.
map-generator-defaults-test and a full non-server engine build pass.

A first attempt instead excluded every site whose deposits sat inside the
clearing box. It tightened the gap to 2.8-3.1 but pushed every colony
roughly twice as far from its resources (worst walk 3.5 -> 6.6 tiles),
trading what matters for what was being measured. Not kept.

Generation costs 63-110ms against 11-14ms, nearly all of it the shortlist
re-scoring, and the first working version cost 1400ms until the visited set
stopped being a linear scan. Imperceptible for a lobby generating one map.
Halving the shortlist halves the cost but loses a third of the gain on
river, so the shortlist stays at 900.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Rc6FTwBEB6LKNUmamX9wWW

Map::growResources decides whether a wheat or wood tile expands with

    dwax = (syncRand()&0xF) - (syncRand()&0xF);   // likewise dway
    expand = isWater(x+dwax, y+dway) && !isSand(x-dwax, y-dway);

The difference of two uniform draws from {0..15} has PMF (16-|d|)/256, so
the chance a tile expands is a triangular kernel summed over every water
tile whose mirror through the tile is not sand. FertilityCalculator fit a
curve to the first half of that and dropped the second: its weights were
int(4.2*sqrt((15-|dx|)*(15-|dy|))) and it never looked at sand at all,
overstating exactly the tiles where wheat will not in fact come back.

Fertility::Field evaluates the real thing in closed form. A length-16
forward box followed by a length-16 backward box is exactly the triangular
kernel, so the water term is four linear passes rather than 961 taps per
grass tile, and the sand term is one stamp per sand tile. Measured over 20
seeds on each of eight generators it runs about ten times faster than the
kernel it replaces (the sand correction, not the convolution, is what it
spends its time on) and correlates 0.89-0.997 with it; shattered-coast,
the sandiest of them, is both the least correlated and the slowest, which
is the difference being paid for.

The field takes plain masks and no Map, so map generation can score a
candidate's growth potential without a live game. FertilityCalculator
keeps its API, its deposit-reachability gate and fertilityMaximum, and
clamps to the Uint16 that Tile::fertility holds; the scale is now 65536,
which the overlay normalises away and MapIO stores per tile as before.

The implementation comes from ExactFertilityCache in AIMaximaFarming on
the Maxima branch, extracted here so both callers share one field.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Rc6FTwBEB6LKNUmamX9wWW

Placement equalises walking distance to wood and wheat, and on four of
these generators that is now down to two tiles for the worst-served
colony. It is also nearly all the metric has left to give: sampling twenty
maps and keeping the fairest shaves two tenths of a tile off a gap of one.

Distance was always a thin account of a starting position. A deposit at
the door that runs dry, a colony with no room to build, one boxed between
two rivals, and one on ground where wheat never grows back all look alike
to it. StartQuality measures six things per colony on the finished map --
where the swarm is built, its clearing cleared and the workers standing
where they will actually start walking -- and folds them into one number
per map: the weakest colony's quality, gated by how evenly the map shared
quality out, worst * (worst/best)^k.

Fertility carries the most weight of the six because it is the one that
decides whether a colony's wheat comes back at all; the others describe
what it starts with, fertility describes what it keeps. Every factor is
normalised against a fixed reference rather than the map's own best
colony, because the point is to rank candidate maps against each other and
a per-map normalisation scores every map alike. The two distances use the
viability bars the study tool already scores against; the other four have
no such bar, so they sit near the ninetieth percentile of what the twelve
generators actually produce, measured over 2400 maps.

Scoring costs 2.5-5.4ms against 11-61ms to generate, consumes no random
stream, and never rejects a map -- it ranks. Map hashes are unchanged.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Rc6FTwBEB6LKNUmamX9wWW

The lobby already generated up to five maps and kept the first that
succeeded, because some rolls cannot fit every starting colony. Among the
rolls that do fit, some still hand one colony far better ground than
another, and now that there is a score for that, the same loop can keep
the best rather than the first.

Five is a budget, not a knee. Keeping the best of K is the maximum of K
draws from a distribution, so it grows like sqrt(2 ln K): it improves
forever and flattens gradually, and bootstrapped over 200 scored maps per
generator all twelve trace that same curve to within a few percent -- three
candidates capture 44% of what fifty give, five 59%, eight 70%, twenty 87%.
What picks the cutoff is that the lobby generates on the UI thread behind a
500ms debounce: at 61ms a candidate on crater-lakes, five rolls cost 306ms
where eight would cost 489ms and spend the whole budget.

The editor owns its Game and cannot hold a spare, so it takes the winning
seed from GenerationService::bestSeed and regenerates it. That is sound
because generation is deterministic and the score is a pure function of the
finished map; map-generator-defaults-test asserts both, along with the
chosen seed being a candidate no other candidate outscores.

Optimising a composite could have pulled colonies away from their resources
to chase fertility or elbow room. Measured, it does not: the worst-served
colony's walk holds at about two tiles on the four height-field generators
and improves by four on shattered-coast, while fairness rises from
0.81-0.94 to 0.92-0.97 everywhere.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Rc6FTwBEB6LKNUmamX9wWW

…d static

Profiling map generation under load (users noticed the "keep the best of five
rolls" work from the previous commit made map generation feel much slower)
found chooseBalancedStarts itself, plus Map::isHardSpaceForGroundUnit called
from inside it, accounting for 74-84% of total generation time on swamp,
river, islands and crater lakes: two whole-map resource floods each call it
once per tile, and then every one of up to 900 shortlisted candidate sites
re-simulates its own local flood calling it again, up to ~4225 tile visits
each in the worst case.

That work was entirely redundant. Every call site in this file uses the same
two constants (canSwim=false, team mask=0), which makes checkTile's forbidden-
area test a no-op, and chooseBalancedStarts runs before placeStarts() ever
places a building, so getBuilding() is NOGBID everywhere it looks. Under
those invariants isHardSpaceForGroundUnit(x, y, false, 0) reduces to
!isResource(x, y) && !isWater(x, y) — a pure function of terrain/resource
state that cannot change across the whole search.

buildHardSpaceGrid() computes that once into a flat std::vector<uint8_t>
before the two distanceToResource() floods; all three flood loops (the two
global ones and scoreAsBuilt's per-site one) read the cached byte instead of
calling through checkTile's several field accessors. distanceToResource's
distance vectors and the per-site visited/visitStamp array are narrowed from
int to 16 bits alongside this — every distance this engine can produce fits
comfortably, and the arrays these floods touch millions of times are half
the size to move through cache.

This changes nothing about which sites get chosen or how they get scored,
only how the unchanged answer is computed: MapGeneratorStudy's per-tile
terrain/resource hash is bit-identical before and after on matching seeds
across every affected generator. Measured 28-31% faster end to end on swamp,
river, islands and crater lakes (interleaved before/after binaries, 60
generations per generator, to separate the effect from this machine's own
run-to-run noise) with zero measurable change on the nine generators that
don't call chooseBalancedStarts, which is the expected result and also rules
out the noise itself producing the improvement.

Verified: full scons client build and scons -C test suite (198 cppunit
cases) pass. MapGeneratorStudy succeeds across all 13 generators at 5 seeds
each, both before and after. FertilityFieldTest and MapGeneratorDefaultsTest
are unaffected (this file's callers are unrelated to either).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CkotX2daY8YTuFcRxFf5ba

Investigated as part of the same profiling pass as the previous commit:
Fertility::Field::rebuild is the dominant cost on Lattice and Maze (57% and
39% of total generation time), but unlike chooseBalancedStarts this is not
redundant recomputation — Fertility::forMap has exactly one caller
(scoreStarts) and runs once per roll, confirmed via its full call chain.

Both generators are simply water/sand-heavy by design (thick maze corridors,
real shorelines): instrumentation shows ~6,100 water and ~1,260 sand tiles
for Lattice and ~4,100/~1,350 for Maze against a 16,384-tile map, and the
sand-correction path costs one 31x31 weighted stamp per sand tile no matter
how the adaptive rule picks between it and the water-splat alternative.

first/second hold the box-blur passes' single-axis partial sums. The first
pass (a plain 16-wide box over 0/1 water values) tops out at 16; combined
with the second, backward pass into the full 1D triangular kernel it tops
out at that kernel's own weight sum, 256; the vertical passes repeat the
same shape against those values, topping out at 16*256=4096. Both fit
uint16_t with no precision loss — the final `fertility` array still needs
32 bits, since its theoretical max (256*256=65536) is one past uint16_t's
range.

This is exact and safe, but measured negligible impact on Lattice/Maze
specifically (their cost is the sand-correction term, which these arrays
aren't part of). Worked through algebraically, that term reduces to
sum_d weight(d) * water(target+d) * sand(target-d) - a bilinear
cross-correlation between two different fields, not the single-field sum
the box-blur trick relies on, so it does not have an equivalent separable
speedup; only FFT-based convolution would change its asymptotic cost, and
Fertility::Field is shared with FertilityCalculator (real gameplay
fertility), so any such rewrite needs to preserve that caller's output
exactly too. Left as an open follow-up rather than attempted here.

Verified: full scons client build and scons -C test suite (198 cppunit
cases, including FertilityFieldTest) pass with no narrowing warnings.
MapGeneratorStudy succeeds across all 13 generators and produces
bit-identical per-tile terrain/resource hashes before and after on matching
seeds.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CkotX2daY8YTuFcRxFf5ba

…ipelago's hot loops

Continuing the same profiling pass as the previous two commits: Shattered
Coast (old-random) and Rugged Archipelago were the slowest and third-slowest
of all 13 generators, and neither bottleneck was in their own terrain logic.

GenerationContext::stream(name) looks up a named std::mt19937 in a
std::map<std::string, std::mt19937>, computing a hash over the name and
walking the tree on every call — cheap on its own, but both generators call
it by string literal from deep inside per-tile loops that run tens of
thousands of times per generation. Shattered Coast's simulateRandomMap
(itself invoked repeatedly per smoothing iteration to balance water/sand/
grass ratios) draws from "simulation" up to five times per tile across every
w*h-tile map it simulates; its terrain() draws from "terrain" the same way
across its own patchwork and smoothing passes. Rugged Archipelago's
island-growing and beach passes draw from "terrain" identically. In every
one of these loops the stream name is a compile-time constant that never
changes for the life of the function, so the repeated lookup was pure
overhead paid on every single draw.

Both functions now look their stream up once into a std::mt19937& at the
top and draw from that reference throughout, instead of calling
context.stream(name) again for every draw. This draws from the exact same
underlying generator in the exact same order, so it changes no random
number either function produces: MapGeneratorStudy's per-tile terrain/
resource hash is bit-identical on matching seeds before and after.

Verified: full scons client build and scons -C test suite (198 cppunit
cases) pass. MapGeneratorStudy succeeds across all 13 generators at 5 seeds
each. Measured 50% faster on Shattered Coast and 31% faster on Rugged
Archipelago end to end (interleaved before/after binaries, 60-100
generations per generator), with ~0% change on two unaffected generators
run the same way, ruling out this machine's run-to-run noise as the source
of the improvement.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CkotX2daY8YTuFcRxFf5ba

…n region splitting

Profiling identified Contested Commons, Concrete Islands and Isles as now the
slowest generators, dominated by the older Voronoi-style point-dispersion
code in shared/Regions.cpp and shared/Distances.cpp. Investigated with cache
behavior specifically in mind.

Exact fixes (same output, only how it's computed - verified by bit-identical
per-tile terrain/resource hashes on matching seeds, every generator):

- computeDistances' BFS used std::queue<int> (std::deque-backed, growing by
  separately heap-allocated blocks) even though every cell is enqueued at
  most once (the `side == 0` guard prevents a second push). A flat,
  preallocated w*h-sized array makes an exact FIFO out of sequential writes
  instead of block-to-block pointer chasing.
- splitUpArea's per-region frontier is inserted at a genuinely random
  position on purpose - that randomness is what gives the flood its organic
  shape, not an accident to remove - but std::vector<int> supports the
  identical random-position insert/erase via a contiguous memmove, without
  std::list's per-node heap allocation and pointer chasing on every single
  insert and on the std::advance that finds where to insert.
- adjustHeightmapFromPerlinNoise and computeAverageDistance are a pure
  per-cell transform and a commutative sum respectively, so nesting y
  outside x costs nothing and walks both the grid and HeightMap's own
  identically row-major _map array with their grain instead of across it.
- getAllPoints, getAllOtherPoints, findBorderPoints, and splitUpPoints's own
  two internal scans all walked a row-major grid as `for x { for y {...} }`
  - a full-row stride on every step - for no reason but habit, except two of
  these results (possible[n], startingPoints[n]) get indexed by a random
  draw, so a plain loop-order swap would silently pick a different point for
  the same seed. collectPointsColumnOrder gets both: a row-major counting
  pass sizes each output column, then a second row-major pass drops each
  point into its precomputed slot, landing every point in the exact x-major,
  y-minor order the original nested loop produced without ever striding
  across the grid to do it. splitUpPoints' single-pass "reset the candidate
  list on every strict improvement" site search reduces to the same set
  every time regardless of how it's computed (traced by hand, confirmed by
  the same hashes), so it is now an explicit two-pass max-then-collect using
  the same helper.

One further fix changes output for Contested Commons specifically:
splitUpPoints' PointSearch::WholeRegion mode (Contested Commons' own search,
not used by any other generator) scores every legal tile as a candidate
placement and keeps only a strict improvement, so whichever tied candidate
is reached earliest in scan order wins - the one shape here a loop-order
swap could not fix without changing anything. Measured directly across 7
seeds: 6 of 7 produce byte-identical maps regardless, and the one that
changed still converges to a placement of the same quality by the search's
own metric (already documented as bounded best-response, not a guaranteed
optimum). PointSearch::Local - used far more broadly, including as
swamp/river/islands/crater lakes' rare legacy fallback - keeps its exact
original scan order untouched: its window is 7x7, too small for traversal
order to matter, and touches far more generators than this fix was worth
risking. Contested Commons' revision bump follows in the next commit.

Verified: full scons client build and scons -C test suite (198 cppunit
cases) pass. MapGeneratorStudy succeeds across all 13 generators at 9 seeds
each. Measured (interleaved before/after binaries, repeated 3x to get past
this machine's run-to-run noise - an initial single-run reading overstated
the effect by more than 2x): Concrete Islands ~9% faster, Isles ~5-7%
faster, Contested Commons ~8-9% faster overall. Fjord Continent, which
touches none of this code, showed ~2% change over the same run, taken as
the noise floor rather than a real effect.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CkotX2daY8YTuFcRxFf5ba

The previous commit's PointSearch::WholeRegion traversal-order change can
change which exactly-tied candidate site wins a placement, so a given seed
can produce a different (equally valid, by the search's own metric) map
than before. Following this repository's existing convention for
generation-output changes, bump the revision so that is visible rather than
a silent side effect.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CkotX2daY8YTuFcRxFf5ba

FEEDBACK 2026-09-13 (third play): "right idea on old town but let's do
1/2 the number of those inwards roads". Old town (revision 5) lays a
tendril every 16 tiles round the fields' cap ring instead of every 8:
some thirty-five on a 256 map.

Verified on macOS arm64: golden table regenerated at revision 5 (264
rows, 0 failures), every Old town lobby cell on seed 1, defaults test,
client build.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GpUW6Ny43aUA1EzThn6cYE

…Canals from play

FEEDBACK 2026-09-13 (first play of each), quoted in the code:

- Marches (25) and Patchwork (33) are removed: "just not working
  conceptually at all" and "the concept is failing". Their ids are
  retired, never reused; shared/Biomes stays in the toolkit.
- Fingerprint (revision 2): "looks very similar to everglades ... a
  higher wavelength has a nicer feel ... feels very empty ... home size
  needs to be larger". Wavelength 30 (was 20), homes of 18 (was 12),
  ambient layer more than doubled.
- Rain shadow (revision 2): "not enough water; ponds deeper and more
  connected; sand roadways through the passes; valleys feel empty;
  rivers to inland lakes; sand patches". Streams 5 deep and 20 long
  every 24; a sand road through every pass and 12 tiles into the
  valley; inland lakes (inland-lakes) with wandering rivers to the
  nearest stream; sand-patches over 6% of the valleys' grass.
- Polder (revision 2): "randomize the angle ... bases way too small,
  growth crowds them out ... 10x4 sand plots at 2.5x the players".
  row-angle is Random / Vertical / Horizontal / Diagonal (Random draws
  any angle and rounds to whole turn counts); villages of 14 in a
  two-tile sand ring; two and a half plots per colony (stampFarmPlot)
  spread through the rows away from the villages.
- Canals (revision 2): "remove the home pond; 1.5x bridges; 2x warp;
  every cell has its own little surprise". Dry home blocks, extra
  bridges 30, warp 80, and every other block dealt one of nine kinds:
  plain, lake, orchard, a 4x4 pad in a sand ring, two pads, quarry,
  woodlot, wheatfield, dune.

Verified on macOS arm64: golden table regenerated (248 rows, 0
failures), --sweep 0 failing combinations, defaults test, strict
translation check, client build.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GpUW6Ny43aUA1EzThn6cYE

A design's home sites come in a fixed order (farthest-point spreading starts
from cell 0, a lattice from its first row), so team 0 always started on the
same ground: top right of Old town, for one. Pipeline.h gains dealStarts, a
shuffle of a design's sites on its own stream, and every designed generator
calls it before anything is keyed by colony index: Fingerprint, Old growth,
Polder, Rain shadow, Canals, Anthill, Old town (homes and annexes together)
and Maze. Validators rebuilding the design from a fresh context get the same
deal. Revisions bumped and the golden table regenerated; a landscape check
covers the deal (a permutation, repeatable, not the identity for most seeds).

Also clears two warnings: an unused Torus alias in Anthill's validator and
Polder's diagonal row width constant, now used for the same value.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GpUW6Ny43aUA1EzThn6cYE

128 maps had no farms (two home ponds instead) because a farm squeezed
between the mountains kept losing a strip to its own coast walls: at
128x256 a strip joined to its field through an isthmus three tiles wide
was sealed off when the walls of the coasts either side met across it,
so the farm-reach check failed and the lobby retried a quarter of seeds.
growFarmFields now keeps only the ground whose eroded core is joined to
the home's core (two cores that do not touch can still overlap once grown
back, through a waist the walls then close); the opening radius is a
parameter with the old default, so Carousel is byte-identical. The size
floor and the pond fallback go; 12 seeds pass at every 128-based cell.
Revision 2, golden rows regenerated.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GpUW6Ny43aUA1EzThn6cYE

Third play: "the farms on switchback still don't seem to expand fully
into the available area ... just ensure that the farms always grow to
fill the available space" and "get rid of the water channels in between
bases, similar to how we had to modify carousel". The fields kept three
tiles of water from each other and from the mountains; on a 256x128 map
that gap, cut through fields grown into fingers, took two fifths of the
open sea and the opening most of the rest. Now the fields grow with no
gap, every tile of sea is filled to its nearest field (fillToNearest with
the whole map as reach), and a single line of stone stands on every
border between colonies (labelBorders), as on Carousel; the farms' rim
drops to 3 since no coast lies beside them. Sea within a level-3 tower's
range of the plateau becomes rock first, so the mountains' inner ends
join round the plateau and no farm reaches it. Revision 3, 12 seeds pass
at every cell from 128x128/2 to 256x256/8, golden rows regenerated.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GpUW6Ny43aUA1EzThn6cYE

Third play: "we need to find a more reliable mechanism to divide the
territory between players for amphitheatre ... wildly unsmooth borders.
lets come up with something fair but also simple and reliable." The
territories were grown a tile at a time by the smallest first with noise
in the cost for a border-roughness control, then smoothed by a majority
filter; the turn-taking grows fingers along every border and smoothing
left them ragged. Territories.h gains balancedTerritories: every tile
outside the wall goes to the colony whose ramp mouth is nearest by
squared distance less a weight, a power diagram whose borders are
straight lines, and the weights are tuned round by round (a step sized
from the shortfall over the border, undone and halved when it made
things worse) until the areas are within 1%. Each colony keeps a disc
round its mouth whatever the balance, so a shifted border never crosses
the way in. Steps and distance-from-arcs were tried first and swing
instead of settling (documented in the header). The roughness control
goes, with its key in all 34 tables. The validator now targets the pit
tile each ramp can reach rather than the very middle, which the orchard
ringed with fruit on some seeds (128x128/4 seed 1 was a golden "failed").
Revision 2; 12 seeds pass at every cell from 128/2 to 256/8.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GpUW6Ny43aUA1EzThn6cYE

Second play: "too many of them are empty of resources. like with the
4x4 squares - those squares are to hold farming buildings. they only
matter if there are resources elsewhere on that island outside the sand
square. can we also add some types that are more like forts? with some
stone that guides enemies into a kill zone or something?" and "a few of
them should be intended for building buildings on of course. but too
many of them are boring right now." The pad kinds are now homesteads
and hamlets with a wheat and a wood clump beside every pad; plain
blocks fall from 24 in 100 to 6; and five kinds built of stone or water
join, each dealt a facing: a fort (a 13-tile square of wall round a pad
with one three-tile gate), a bastion (four corner walls, an opening in
every side), a funnel (two walls in a V onto a three-tile gap, the pad
behind it), a chicane (two staggered walls with a corridor between) and
a moat (a ring of water round an islet with a pad and one sand
causeway). Walls are drawn in the block's frame only where the warp
left pure grass clear of water, and a block whose walls would cut its
land or a bridge off gets none (blockWalls). Every pad and built kind
carries the ambient fields too (15/10 in 100 of fertile tiles), a tile
clear of the walls. Validator checks every wall's stone and every moat.
Revision 4; 12 seeds pass at 128/2 to 512/4.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GpUW6Ny43aUA1EzThn6cYE

A self-review of the generators built and revised this week, with the
golden table unchanged (248 rows, 0 failures) as the proof that no map
moved. Boilerplate every designed generator copied goes into the
toolkit: designFailure<design> (the registry's request check), and in
Pipeline.h settleRoundColonies with homeGrassMask (round homes settled
on their own grass) and homePondMissing (the validators' pond check);
nearestSiteDistance (Orbits.h) replaces four copies of the same loop
and tilePoint (Tessellation.h) two. Anthill keeps one list of chamber
kinds (ChamberKind) instead of computing it in design and again in
generate. Stale comments corrected: Switchbacks' pre-fill farm paragraph
and "water between mountains" wording, Old town's wall (removed after
the first play), Rain shadow's stream sizes, Old growth's pool-ring
distance, Canals' "market blocks" that never existed, Polder's and
Anthill's superseded defaults, Amphitheatre's removed roughness control;
debug includes dropped. The four control keys left by the deleted
Marches and Patchwork generators go from all 32 tables that held them,
and the docs name the new helpers.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GpUW6Ny43aUA1EzThn6cYE

The nine landscapes and three walled arenas registered 47 strings that
were left as English fallbacks in all 32 catalogs, and CI's translation
gate fails on the first fallback it sees. Every one now has a translation,
aligned with each catalog's existing terms for ridges, passes, homes and
resources. Where a catalog's own word is spelled as the English is (Polder
in the Germanic and most Slavic catalogs, Coral in es/pt/ro, Spiral in
dk/id/sv/tr, Plazas in es, Canals in ca, Grain in fr, Diagonal in de/id)
the word is listed as shared vocabulary in
test/translation_shared_values.json rather than reworded.

Seven keys no generator refers to any more (Marches, March width,
Patchwork, Orchards, Straight, Gates and the old home-size failure) are
removed from texts.keys.txt and every catalog.

texts.br.txt is Brazilian Portuguese; an earlier pass wrote about fifty of
this branch's entries (Coral, Spider web and the walled arenas) in Breton.
They are rewritten in Portuguese, following texts.pt.txt with Brazilian
forms (colônia, trilha, fazenda, menor).

Verified: data/check_translations.py --strict, test/test_translations.py,
test/test_font_coverage.py and test/test_text_area_layout.py all pass.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GpUW6Ny43aUA1EzThn6cYE

… style

Four items from the review of b86c59b:

- Tessellation.cpp named a vector `near`, a legacy windef.h macro that
  expands to nothing on mingw and broke the Windows build. Renamed
  `nearby`.
- makeHomogenMap, controlSand and smoothResources had been folded into
  MapTerrain.cpp, which test/SConstruct links against a stripped
  server-mode libgag with no globalContainer, so the unit-test build no
  longer linked. They are back in their own translation unit,
  src/map/generator/MapHomogen.cpp, listed with the generator sources;
  nothing outside the generators and their tests calls them.
- Stone Highlands' nearbyValleys returned before its sort when a fourth
  valley was in the window, so a valley pair could key the anyPair map in
  either order and the fallback pass-carving saw split candidate lists.
  The helper now keeps a sorted three-slot set and always returns it
  sorted. The same shape removes the std::sort over a runtime-bounded
  raw array that GCC 15 flagged with -Warray-bounds. The generator's
  revision moves to 3; the golden rows for the sampled seeds are
  unchanged, so the fix only bites where the fallback ran.
- Glob2.cpp had two includes above its SPDX header and three
  space-indented lines in a tab-indented file.

Verified: scons release=1 builds with no warnings; MapGeneratorDefaultsTest
passes; MapGeneratorGoldenTest passes after --update (only the Stone
Highlands revision column changed); test/MapExploredAreaSaveLoadTest builds
and passes.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GpUW6Ny43aUA1EzThn6cYE

Brings in the CORN -> WHEAT identifier rename (#269) and the status-bar
clamp (#194). The rename is applied to every file this branch adds or
changes: 158 identifiers and comments across the generators, the shared
toolkit, the generator tests and tools/MenuColonyHarness.cpp, so the
branch has no CORN left outside the cortex-ml Python tools master also
left alone. The five legacy generator files master renamed inside were
already deleted here; FertilityCalculator.cpp, MapHomogen.cpp and
MapGeneratorStudy.cpp keep this branch's versions with the rename applied.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GpUW6Ny43aUA1EzThn6cYE

…ences

- MapGeneratorGoldenTest gains --require-rows: the same check, but a
  platform with no rows in the table fails instead of reporting and
  passing. The plain check keeps passing on a rowless platform so a new
  machine can run it before its rows exist. CI will pass the flag once the
  linux-x86_64 rows are committed; until then the workflow runs --print
  before the check, so the rows a platform would record are in the log
  even when the check fails.
- CustomGamePreferences bounded the legacy riverDiameter slot at 100, and
  Old growth's lake size, which shares that slot, reaches 160: a saved
  lobby with a big lake failed to load and fell back to defaults, and
  CustomGameSetupHarness's whole-range round trip caught it. The envelope
  is now 0-160.

Verified: CustomGameSetupHarness passes in default, preferences-write and
preferences-read modes; MapGeneratorGoldenTest passes with and without
--require-rows on macos-arm64; --sweep reports 0 failing combinations;
test/TestsRunner and every test/ harness pass; MenuColonyHarness check and
navigation pass.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GpUW6Ny43aUA1EzThn6cYE

The 248 linux-x86_64 rows come from the --print output of CI run
34839155040 on c6fb9d5; the ubuntu 22.04 (g++ 11) and 24.04 (g++ 13)
jobs printed identical rows, so one platform tag covers both. 156 of the
rows match macos-arm64 hash for hash; the other 92 are the generators
that go through floating point (Fjord continent, Watershed at 512, Ring
world and others), which is the per-platform caveat the table was
designed around.

With the rows in, the workflow runs the check as --require-rows, so a
Linux job can no longer pass this step with nothing to compare, and the
test README and framework reference say where a new platform's rows
come from.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GpUW6Ny43aUA1EzThn6cYE

windef.h defines both as empty macros, and the Windows job stopped at
Territories.h's `const int far` once Tessellation.cpp compiled. Every
remaining use as an identifier is renamed: farthest in Morphology.cpp
and Territories.h, clearance for the distance-to-keep-clear vectors in
Old growth, Old town and Polder, and nearby/distant in the two test
headers. Pure renames; the golden table is unchanged and the defaults
test passes.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GpUW6Ny43aUA1EzThn6cYE

…enerators

The Windows job failed SavegameSafetyHarness's check that a save leaves
the sync RNG untouched, with the same harness and save code master
passes there; the only change to the RNG on this branch is that
`randomGenerator` became `thread_local`. A thread_local with a
constructor that other translation units name directly is initialised
through a weak per-unit wrapper, which mingw's emulated TLS is the one
platform to get wrong. The engine is now a function-local thread_local
behind `syncRandEngine()`, initialised in one place in Utilities.cpp,
and every former use of the object (save and load, the menu colony's
swap, the generation service's scope, the harnesses) calls the accessor.
Same semantics everywhere else: golden maps, the defaults test, the
savegame and trapped-unit harnesses and the setup harness all pass
unchanged on macOS.

The savegame harness now prints both RNG states when they differ
instead of a bare assert, so the next platform that disagrees says how.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GpUW6Ny43aUA1EzThn6cYE

…down

- The custom game screen opens on a random map at four colonies when nothing
  is saved; the premade library preselects FourSquares1 the first time it is
  opened. A saved lobby still restores every setting, generator options
  included (verified by the preferences harness modes).
- Reset to defaults moves to the top of the map column, right under the
  landscape chooser, with Random parameters beside it: every one of the
  landscape's controls drawn at random (GenerationRequest::randomizeControls),
  a set the generator refuses redrawn on the spot and one the world refuses
  redrawn when the preview's candidates come back empty, up to six times, so
  the first set that generates a valid map is the one shown.
- The landscape picker gains Randomize parameters beside Regenerate all, with
  the same redraw rule per tile (LandscapePreviewer::reroll), and Use hands the
  lobby the parameters the shown map was rolled with as well as its seed.
- Under a generated map's preview: its fairness and score, and an (i) that
  opens StartQualityScreen, the per-colony breakdown of what was measured, how
  each factor scored, the weights and the totals.
- Labels that do not fit a compact button take the small font.
- 13 new UI strings in all 32 catalogs; MenuColonyHarness drives the preview
  before reading the map header; CustomGameSetupHarness covers the new buttons,
  the breakdown screen and the picker's randomize. Docs updated in
  docs/custom-game-setup/README.md.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GpUW6Ny43aUA1EzThn6cYE